(This really applies to the RFD #407, but I am pasting it here as well for completeness)

Sorry to completely ignore the FCP, in my defense this was discussed at the 2025-07-17 QWG meeting and is still not decided.

IIUC artifactID and artifactType indicate an OmniBOR "type" of affected object and not something more generic, right? My first thought is, if we're adding a new type (and I'm in favor of new product identification types, including OmniBOR), explicitly declare the type and design a structure that supports multiple types. Related, there was a comment that Maven uses artifactID in some way.

Rough example within .containers.cna.affected

{
  "vendor": "Example.org",
  "product": "Example Enterprise",
  "defaultStatus": "affected",
  "identifierType": "OmniBOR",
  "identifierSpecific:" {
    "artifactID": "gitoid:blob:sha256:fee53a18d32820613c0527aa79be5cb30173c823a9b448fa4817767cc84c6f03",
    "artifactType": "artifact"
  }
}

I would argue that the design had been decided, hence the FCP, and that yesterday's QWG meeting was relitigating a number of issues which had been covered in prior meetings and in the issue tracker.

That said, I will be renaming the fields to include "omnibor" in the name, per the discussion in yesterday's meeting.

As for the specific concept proposed here for new identifiers, I do think this would be inconsistent with existing "identifier pair types" like vendor and product or collectionURL and packageName, which appear together per the constraints on the object type. It's not clear to me why we'd do this grouping for new identifiers when we don't do it for existing ones. As proposed, it would also mean you could use only one "new identifier" within the product object, since you can't repeat fields in a JSON object.

Thanks and I realize I'm behind in the discussion and decisions on this and am contributing to relitigation, which is generally bad form. I suspect adding "omnibor" to field names addresses my short term concern, and longer term, my concerns fall up to an overhaul of the (poorly named) affected object. At a requirement level, I'd want something like "at least one type of identifier from an approved list plus zero or more additional identifiers that mean entirely or substantially the same thing." In my example JSON above, that could be an array of identifierType elements.

To be clear, my comments are not meant to block merging this PR, subject to whatever additional changes are in flight.

Thanks, and I agree there's a need to do a larger rework of the affected array in a future 6.0.0 version of the Record Format!

The field names and constraints have been updated to reflect the changes discussed in the last two QWG meetings.

Ah, it appears the older version of the JSON Schema spec we use doesn't support "dependentRequired" constraints, so I'll have to reformulate that constraint using the older mechanisms. I'll make a commit that corrects the error.

It would also be nice if it were easier to catch these kinds of issues locally.